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There  are  many  requirements  elicitation  methods,  but  we  seldom  see  elicitation  performed  specifically  for  security  requirements. 

One  reason  for  this  is  that few  elicitation  methods  are  specifically  directed  at  security  requirements.  Another factor  is  that  orga¬ 
nisations  seldom  address  security  requirements  elicitation  specifically  and  instead  lump  them  in  with  other  traditional  require¬ 
ments  elicitation  methods.  This  article  describes  an  approach  for  doing  trade-off  analysis  among  requirements  elicitation  meth¬ 
ods.  Several  case  studies  were  conducted  in  security  requirements  elicitation;  the  detailed  results  of  one  case  study  and  brief 
results  of  two  other  case  studies  are  presented  here. 


A  largely  neglected  area  in  requirements 
engineering  is  that  of  elicitation 
methods  for  security  requirements.  Many 
organizations,  if  they  use  an  elicitation 
method  at  all  for  security  requirements, 
use  one  that  they  have  previously  used  for 
ordinary,  functional  (end-user)  require¬ 
ments.  Alternatively,  they  may  decide  to 
use  a  brainstorming  approach.  Such  meth¬ 
ods  are  usually  not  oriented  towards  secu¬ 
rity  requirements  and  do  not  result  in  a 
consistent  and  complete  set  of  security 
requirements. 

Carnegie  Mellon  University  (CMU) 
graduate  students,  working  with  me,  select¬ 
ed  and  applied  several  elicitation  methods 
in  a  series  of  case  studies  [1],  In  this  arti¬ 
cle,  I  describe  a  trade-off  analysis  that  we 
used  to  select  a  suitable  requirements  elici¬ 
tation  method  and  present  results  detailed 
from  a  case  study  of  one  method  and  a 
series  of  two  other  methods,  used  in  a 
series  of  case  studies.  While  results  may 
vary  from  one  organization  to  another,  tire 
discussion  of  our  selection  process  and 
tire  example  results  should  apply  to  all. 

Elicitation  Methods 

The  following  is  a  sample  of  methods  that 
could  be  considered  for  eliciting  security 
requirements. 

Misuse  Cases 

Misuse  cases  apply  the  concept  of  a  nega¬ 
tive  scenario  -  that  is,  a  situation  that  the 
system’s  owner  does  not  want  to  occur  -  in 
a  use-case  context.  For  example,  business 
leaders,  military  planners,  and  game  play¬ 
ers  are  familiar  with  analyzing  their  oppo¬ 
nents’  best  moves  as  identifiable  threats. 
By  contrast,  use  cases  generally  describe 
behavior  that  die  system  or  entity  owner 
wants  the  system  to  show  [2],  Use-case 
diagrams  have  proven  quite  helpful  for  the 
elicitation  of  requirements. 

Soft  Systems  Methodology  (SSM) 

SSM  deals  with  problem  situations  in 


which  there  is  a  high  social,  political,  and 
human  activity  component  [3].  The  SSM 
can  deal  with  soft  problems  that  are  difficult 
to  define,  rather  than  hard  problems  that  are 
more  technology  oriented.  Examples  of 
soft  problems  are  how  to  deal  with  home¬ 
lessness,  how  to  manage  disaster  planning, 
and  how  to  improve  Medicare.  Eventually, 
technology-oriented  problems  may  emerge 
from  these  soft  problems,  but  much  more 
analysis  is  needed  to  get  to  that  point. 

Quality  Function  Deployment  (QFD) 

QFD  is  an  overall  concept  that  provides  a 
means  of  translating  customer  require¬ 
ments  into  the  appropriate  technical 
requirements  for  each  stage  of  product 
development  and  production  [4],  The  dis¬ 
tinguishing  attribute  of  QFD  is  the  focus 
on  customer  needs  throughout  all  product 
development  activities.  By  using  QFD, 
organizations  can  promote  teamwork,  pri¬ 
oritize  action  items,  define  clear  objec¬ 
tives,  and  reduce  development  time. 

Controlled  Requirements 
Expression  (CORE) 

CORE  [5,  6]  is  a  requirements-analysis 
and  specification  method  that  clarifies  the 
user’s  view  of  die  services  to  be  supplied 
by  the  proposed  system.  In  CORE,  the 
requirements  specification  is  created  by 
die  user  and  the  developer,  not  one  or  the 
other.  The  problem  to  be  analyzed  is 
defined  and  broken  down  into  user  and 
developer  viewpoints.  Information  about 
die  combined  set  of  viewpoints  is  then 
analyzed.  The  last  step  of  CORE  deals 
with  constraints  analysis  such  as  die  limi¬ 
tations  imposed  by  that  system’s  opera¬ 
tional  environment  in  conjunction  with 
some  degree  of  performance  and  reliabil¬ 
ity  investigation. 

Issue-Based  Information  Systems 
(IBIS) 

IBIS,  developed  by  Horst  Rittel,  is  based 
on  the  principle  that  the  design  process 


for  complex  problems,  which  Rittel  terms 
wicked  problems,  is  essentially  an  exchange 
among  the  stakeholders  in  which  they 
bring  dieir  personal  expertise  and  perspec¬ 
tive  to  die  resolution  of  design  issues  [7], 
Any  problem,  concern,  or  question  can  be 
an  issue  and  may  require  discussion  and 
resolution  in  order  for  the  design  to  pro¬ 
ceed.  The  IBIS  model  centers  on  the  dis¬ 
cussion  and  resolution  that  is  an  integral 
part  of  the  design  process. 

Joint  Application  Development  (JAD) 

JAD  [8]  is  specifically  designed  for  the 
development  of  large  computer  systems. 
The  goal  of  JAD  is  to  involve  all  stake¬ 
holders  in  the  design  phase  of  die  product 
via  highly  structured  and  focused  meet¬ 
ings.  In  the  preliminary  phases  of  JAD, 
the  requirements-engineering  team  is 
tasked  with  fact  finding  and  information 
gadiering.  Typically,  the  outputs  of  this 
phase  -  as  applied  to  security  require¬ 
ments  elicitation  -  are  security  goals  and 
artifacts.  The  actual  JAD  session  is  dien 
used  to  validate  this  information  by  estab¬ 
lishing  an  agreed-upon  set  of  security 
requirements  for  the  product. 

Feature-Oriented  Domain  Analysis 
(FODA) 

FODA  is  a  domain  analysis  and  engineer¬ 
ing  method  that  focuses  on  developing 
reusable  assets  [9],  By  examining  related 
software  systems  and  the  underlying  theo¬ 
ry  of  the  class  of  systems  they  represent, 
domain  analysis  can  provide  a  generic 
description  of  the  requirements  of  that 
class  of  systems  in  the  form  of  a  domain 
model,  and  a  set  of  approaches  for  their 
implementation. 

The  FODA  method  was  founded  on 
two  modeling  concepts:  abstraction  and 
refinement.  Abstraction  is  used  to  create 
domain  models,  as  described  above,  from 
the  specific  applications  in  the  domain. 
Specific  applications  in  the  domain  are 
developed  as  refinements  of  the  domain 
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Table  1:  Comparison  of  Elicitation  Methods 


models.  The  example  domain  used  in  the 
report  [9]  is  that  of  window-management 
systems. 

Critical  Discourse  Analysis  (CD A) 

CDA  uses  sociolinguistdc  methods  to  ana¬ 
lyze  verbal  and  written  discourse  [10].  In 
particular,  CDA  can  be  used  to  analyze 
requirements  elicitation  interviews  and  to 
understand  the  narratives  and  stories  that 
emerge  during  requirements  elicitation 
interviews. 

Accelerated  Requirements  Method 
(ARM) 

ARM  is  a  facilitated  requirements  elicita¬ 
tion  and  description  activity  process  [11]. 
Overall,  there  are  three  phases  of  the 
process:  Preparation  phase,  Facilitated 
Session  phase,  and  Deliverable  Closure 
phase.  The  ARM  process  is  similar  to 
JAD,  but  it  also  has  certain  significant  dif¬ 
ferences  with  respect  to  the  baseline  JAD 
method.  In  the  ARM  process,  the  facilita¬ 
tors  are  content-neutral,  the  group 
dynamic  techniques  used  are  different 
from  those  used  in  JAD,  the  brainstorm¬ 
ing  techniques  used  are  different,  and  the 
requirements  are  recorded  and  organized 
using  different  conceptual  models. 

Evaluation  Criteria 

The  following  are  example  evaluation  cri¬ 
teria  (project  participants  need  to  have  a 
common  understanding  of  what  they 
mean  in  order  to  use  them  in  selecting  an 
elicitation  method): 

•  Adaptability.  The  method  can  be 
used  to  generate  requirements  in  mul¬ 
tiple  environments.  For  example,  the 
elicitation  method  works  equally  as 
well  with  a  software  package  that  is 
near  completion  as  with  a  project  in 
the  planning  stages. 

•  Computer-aided  software  engineer¬ 
ing  (CASE)  tool.  The  method 
includes  a  CASE  tool.  (The  Software 
Engineering  Institute  [SEI]  defines  a 
CASE  tool  as  a  computer-based  product 
aimed  at  supporting  one  or  more  software 
engineering  activities  within  a  software  devel¬ 
opment  process  [1].) 

•  Stakeholder  acceptance.  The  stake¬ 
holders  are  likely  to  agree  on  the  elici¬ 
tation  method  in  analyzing  their 
requirements.  For  example,  die  method 
is  not  too  invasive  in  a  business  envi¬ 
ronment  and  can  be  implemented  in  a 
reasonable  amount  of  time. 

•  Easy  implementation.  The  elicita¬ 
tion  method  is  not  overly  complex  and 
can  be  properly  executed  easily. 

•  Graphical  output.  The  method  pro¬ 
duces  readily  understandable  visual 


artifacts. 

•  Quick  implementation.  The  require¬ 
ments  engineers  and  stakeholders  can 
fully  execute  the  elicitation  method  in 
a  reasonable  length  of  time. 

•  Shallow  learning  curve.  The  require¬ 
ments  engineers  and  stakeholders  can 
fully  comprehend  the  elicitation  method 
within  a  reasonable  length  of  time. 

•  High  maturity.  The  elicitation  method 
has  experienced  considerable  exposure 
and  analysis  in  its  vetting  by  the  require¬ 
ments  engineering  community. 

•  Scalability.  The  method  can  be  used 
to  elicit  the  requirements  of  projects  of 
different  sizes,  from  enterprise-level 
systems  to  small-scale  applications. 

Ranking  Against  the  Criteria 

The  elicitation  methods  can  be  ranked 
against  the  criteria  using  a  tabular  form.  In 
Table  1,  we  have  filled  in  the  values  that 
the  student  team  decided  on  for  the  sam¬ 
ple  methods.  Each  method  was  rated 
according  to  the  desired  features,  and  the 
rankings  were  simply  added  to  provide  a 
summary  result.  A  weighted  average  could 
also  have  been  used  if  some  features  were 
considered  to  be  more  important  than 
others.  For  example,  availability  of  a 
CASE  tool  might  be  more  important  than 
graphical  output.  A  typical  weighting 
scheme  could  consider  criteria  to  be  essen¬ 
tial  with  weight  3,  desirable  with  weight  2, 
and  optional  with  weight  1.  This  sort  of 
evaluation  is  subjective,  particularly  since 
the  students  worked  under  time  con¬ 
straints  and  did  not  have  prior  experience 
with  this,  so  results  may  vary.  Each  orga¬ 
nization  or  project  should  develop  its  own 
comparison  criteria  and  its  own  ratings. 

In  our  case  studies,  we  decided  to  use 
JAD,  ARM,  and  IBIS  on  three  different  pro¬ 
jects.  These  three  methods  were  subjectively 
ranked  to  be  the  most  suitable  candidates 


for  the  case  studies,  given  our  constraints. 
The  student  team’s  allotted  time  was  con¬ 
strained,  since  this  was  a  one-semester  pro¬ 
ject.  It  was  also  the  case,  however,  that  the 
clients  had  limited  time  to  devote  to  this 
exercise.  Therefore,  time  constraints  are 
mentioned  several  times. 

It  is  important  to  note  that  although 
students  did  the  elicitation,  the  projects 
studied  were  real  industry  and  government 
projects,  not  software  projects  developed 
by  students  in  an  academic  setting.  It  is 
also  possible  that  a  combination  of  meth¬ 
ods  may  work  best.  This  should  be  con¬ 
sidered  as  part  of  the  evaluation  process. 

Security  Requirements 
Elicitation  Results 

In  this  section,  we  present  brief  results 
for  IBIS  and  JAD  and  detailed  results 
for  ARM.  Detailed  results  for  all  three 
methods  can  be  found  in  the  Require¬ 
ments  Engineering  section  of  the 
BuildSecurityln  Web  site  [12]  and  in  the 
case  study  report  [1], 

Brief  Results  for  IBIS 

The  effectiveness  of  IBIS  in  eliciting  secu¬ 
rity  requirements  depends  on  the  quality 
of  the  interview  questions.  To  the  greatest 
extent  possible,  the  scope  of  questions 
must  cover  the  entire  range  of  security 
requirements  that  could  possibly  involve 
the  system.  We  found  that  the  interviewer 
must  be  persistent  in  encouraging  the 
stakeholders  to  explain  their  rationale 
when  proposing  a  solution  to  an  issue.  By 
explaining  why  they  have  chosen  such  a 
position,  the  stakeholders  can  naturally 
discuss  the  pros  and  cons  among  them¬ 
selves.  In  addition  to  proper  question 
selection,  we  found  that  the  success  of 
IBIS  is  direcdy  proportional  to  the  variety 
and  level  of  participation  of  stakeholders 
in  the  project.  In  fact,  in  our  case  study, 
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IBIS  worked  best  when  different  stake¬ 
holders  presented  opposing  viewpoints, 
which  is  common  in  large-scale  projects. 
The  Compendium  software  tool  associat¬ 
ed  with  IBIS  was  easy  for  the  student  team 
to  use  and  effective  in  generating  IBIS 
maps.  To  avoid  displaying  extremely  large 
maps  (which  our  stakeholders  found  diffi¬ 
cult  to  read),  we  recommend  exploiting 
die  nested  maps  feature  in  Compendium. 
This  feature  enables  die  user  to  hide  some 
of  the  lower-level  details  of  die  maps  by 
nesting  them  inside  other  map  elements, 
while  maintaining  the  ability  to  drill  down 
into  the  details  if  requested.  In  fact,  a 
comment  received  from  the  stakeholders 
indicated  that  such  a  hierarchical  map 
structure  would  have  been  more  beneficial 
in  handling  some  of  the  larger  maps. 

Brief  Results  for  JAD 

Due  to  time  constraints,  we  did  not  define 
the  work  flow,  data  elements,  screens,  and 
reports  of  the  project,  so  the  JAD 
method  turned  out  to  be  very  similar  to 
an  unstructured  interview  process. 
Although  unstructured  interviews  were 
used  in  an  earlier  case  study,  we  did  not 
attempt  to  do  a  direct  comparison  of  the 
JAD  results  with  those  earlier  case  study 
results.  In  essence,  the  team  just  asked  the 
stakeholders  some  questions  about  the 
project.  Thus,  the  team  did  not  use  the 
full  capability  of  the  JAD  method,  which 
may  have  biased  the  results.  The  JAD  ses¬ 
sion  phase  was  designed  for  developing 
functional  (end  user)  requirements;  there 
was  no  specific  way  to  discuss  quality 
requirements  such  as  security.  Therefore, 
the  team  spent  a  lot  of  time  researching 
other  methods  to  assist  in  obtaining  bet¬ 
ter  security  requirements  during  the  JAD 
session.  The  team  suggests  that  JAD  be 
used  with  an  additional  method  to  deal 
with  quality  requirements. 

Detailed  Results  for  ARM 

Results  obtained  using  ARM  on  a  govern¬ 
ment  project  are  described  below.  This  is 
not  a  military  project,  but  the  security  con¬ 
cerns,  such  as  access  control,  are  similar  to 
die  typical  security  concerns  of  military 
projects.  ARM  is  designed  to  elicit,  cate¬ 
gorize,  and  prioritize  security  require¬ 
ments.  As  noted  earlier,  the  ARM  method 
includes  three  phases. 

Preparation  Phase 

As  die  name  implies,  this  phase  is  used  to 
prepare  for  the  Session  phase.  There  are 
six  steps  in  the  Preparation  phase: 

1.  Define  goals,  objectives,  and  project 
success  criteria  (PSC)  of  the  project. 

2.  Define  objectives  and  preliminary 


scope  of  the  session. 

3.  Establish  partitions  and  identify  par¬ 
ticipants. 

4.  Determine  environmental  and  logisti¬ 
cal  aspects. 

5.  Establish  expectations  for  participants. 

6.  Communicate  widi  participants. 

One  way  to  obtain  this  information  is 
to  use  a  feedback  form  composed  of 
questions  for  the  stakeholders.  The  list  of 
questions  can  be  found  in  the  case  study 
report  [1],  The  stakeholders  should  be 
given  a  few  business  days  to  complete  and 
return  die  form.  In  die  meantime,  the 
requirements  engineering  team  can  pre¬ 
pare  a  memorandum  containing  goals, 
objectives,  PSC,  preliminary  scope,  parti¬ 
tion  definitions,  participants,  and  logistic 
arrangements.  Participants  should  read  the 

Results  obtained  using 
ARM  on  a  government 
project  are  described 
here.  This  is  not  a 
military  project,  but  the 
security  concerns,  such 
as  access  control, 
are  similar  to  the 
typical  security  concerns 
of  military  projects. 

memorandum  before  die  Session  phase  to 
understand  the  content,  expectation,  and 
goals  of  the  method.  The  overall  goal  of 
die  memorandum  is  to  increase  the  quali¬ 
ty  of  the  Session  phase. 

Depending  on  die  results  of  the  stake¬ 
holders’  feedback  forms,  anodier  meeting 
with  the  stakeholders  may  be  necessary 
before  beginning  the  Session  phase. 

Session  Phase 

The  Session  phase  is  die  heart  of  the 
ARM  process.  It  includes  six  steps: 

1 .  Executive  sponsor  commentary. 

2.  Scope  closure. 

3.  Brainstorm,  organize,  and  name  (BON). 

4.  Details. 

5.  Prioritization. 

6.  Participant  feedback. 

Before  the  Session  phase  meeting,  logisti¬ 
cal  arrangements  should  be  made  to 
ensure  that  the  meeting  goes  smoothly. 
The  detailed  list  of  logistical  items  can  be 


found  in  the  case  study  report  [1], 

Executive  Sponsor  Commentary. 

This  step  allows  executive  sponsors  to 
provide  introductory  remarks  to  the  par¬ 
ticipants  regarding  the  planned  session. 
Depending  on  the  project  organization, 
this  step  may  or  may  not  be  necessary. 

Scope  Closure.  The  purpose  of  this 
step  is  to  define  what  is  in  or  out  of  scope. 
When  eliciting  security  requirements,  par¬ 
ticipants  might  need  to  familiarize  them¬ 
selves  with  security  issues  ahead  of  time 
to  make  this  determination. 

BON.  The  BON  step  provides  an  effi¬ 
cient  way  to  elicit  the  candidate  require¬ 
ments  from  participants.  The  require¬ 
ments  engineering  team  can  start  by  ask¬ 
ing  the  participants  the  focus  question,  which 
should  be  crafted  to  tie  to  the  goals,  objec¬ 
tives,  and  scope  of  the  project  togedier. 
For  example:  An  important  security  require¬ 
ment  of  the  beta  application  is. . .  Based  on 
their  professional  experience  and  security 
knowledge,  the  participants  are  then  asked 
to  write  down  seven  important  security 
requirements  within  seven  minutes. 

Next,  die  participants  are  asked  to 
write  their  top  three  or  four  security 
requirements  on  cards  within  three  min¬ 
utes.  The  requirements  engineering  team 
then  collects  the  cards  and  displays  the 
candidate  security  requirements.  The  can¬ 
didate  security  requirements  produced  in 
this  example  are  listed  in  the  following  24 
initial  requirements  produced  in  ARM: 

1 .  The  ability  to  securely  transmit  data  to 
remote  sources. 

2.  The  preservation  of  data  integrity. 

3.  The  enforcement  and  usability  of  an 
access  control  system. 

4.  Manageable  security  (and  not  hinder 
business  where  possible). 

5.  A  strong,  reliable  authentication 
process. 

6.  Private  information  (from  die  outside 
world). 

7.  Consistent  application  program  inter¬ 
faces  (APIs). 

8.  Data  integrity. 

9.  Audientication  and  access  control. 

10.  Strong  authentication. 

1 1 .  Risk  reduction  or  elimination  of  risk 
of  inappropriate  behavior. 

12.  Granular  access  to  data  for  users 
(operators)  and  customers. 

1 3.  Accountability  (who  did  what,  when, 
how...). 

14.  Integrity  (assurance  in  data  protection 
and  validity). 

15.  Indelibility  (deletions  and  retractions 
are  noted/logged). 

1 6.  Integrity. 

17.  Access  control. 
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18.  Confidentiality  (encryption,  etc.). 

19.  Partitioned  data  store  (public  read  only 
and  private  read/write). 

20.  Selectively  secure  communication  with 
outside  entities. 

21 .  Segmented  disclosure  representation 
and  support. 

22.  Role-based  restricted  views/ edit/  action 
access  (e.g.,  summary  report  informa¬ 
tion,  public  for  particular  people). 

23.  24/7  availability  via  remote  authenti¬ 
cated  access  and  secure. 

24.  Key  action  audit  (e.g,  attribution  of 
who/ from  where  the  publish  button 
was  pressed,  what  changes  were 
made). 

In  the  Organize  step,  all  the  partici¬ 
pants  review  the  candidate  security 
requirements  generated  during  die  brain¬ 
storming  session  to  see  whether  any  dupli¬ 
cate  or  inadequate  security  requirements 
were  included.  Then  the  participants  dis¬ 
cuss  what  they  think  are  important 
requirements.  This  step  provides  an 
opportunity  for  the  participants  to  share 
their  security  concerns  about  the  project. 
After  a  period  of  discussion  and  debate, 
they  delete  candidate  security  require¬ 
ments  that  are  viewed  as  redundant  or 
inappropriate. 

The  participants  removed  require¬ 
ments  1,  2,  5,  9,  14,  16,  and  17.  The 
remaining  requirements  after  initial  elimi¬ 
nations  are: 

3.  The  enforcement  and  usability  of  an 
access  control  system. 

4.  Manageable  security  (and  not  hinder 
business  where  possible). 

6.  Private  information  (from  the  outside 
world). 

7.  Consistent  APIs. 

8.  Data  integrity. 

10.  Strong  authentication. 

1 1 .  Risk  reduction  or  elimination  of  risk 
of  inappropriate  behavior. 

12.  Granular  access  to  data  for  users 
(operators)  and  customers. 

13.  Accountability  (who  did  what,  when, 
how...). 

15.  Indelibility  (deletions  and  retractions 
are  noted/logged). 

18.  Confidentiality  (encryption,  etc.). 

19.  Partitioned  data  store  (public  read  only 
and  private  read/ write). 

20.  Selectively  secure  communication  with 
outside  entities. 

21 .  Segmented  disclosure  representation 
and  support. 

22.  Role-based  restricted  views/edit/  action 
access  (e.g,  summary  report  informa¬ 
tion,  public  for  particular  people). 

23.  24/7  availability  via  remote  authenti¬ 
cated  access  and  secure. 

24.  Key  action  audit  (e.g,  attribution  of 


who/ from  where  the  publish  button 
was  pressed,  what  changes  were 
made). 

In  the  Name  step,  the  participants  are 
instructed  to  group  the  selected  security 
requirements  and  create  names  for  each 
group.  In  this  example,  security  require¬ 
ments,  groups,  and  names  were  generated 
together  and  descend  in  order  of  impor¬ 
tance  from  A-F  (as  shown  in  Figure  1, 
page  18).  The  security  requirements  are 
categorized  into  six  groups,  each  contain¬ 
ing  between  one  and  four  security  require¬ 
ments.  This  step  can  result  in  addition  or 
deletion  of  requirements.  The  following 
are  the  grouped  requirements  contained  in 
each: 

•  Group  A:  Confidentiality:  Information 
must  be  kept  private  from  the  outside 
world;  communication  with  outside 
entities  must  be  selectively  secured. 

•  Group  B:  Access  Control:  Role -based 
restricted  views/edit/action  access 
(e.g,  summary  report  information, 
public  for  particular  people);  enforce¬ 
ment  and  usability  of  an  access  control 
system;  granular  access  to  data  for 
users  (operators)  and  customers;  seg¬ 
mented  disclosure  support  and  repre¬ 
sentation. 

•  Group  C:  Data  Integrity:  Partitioned 
data  store  (public  read  only  and  private 
read/write);  indelibility. 

•  Group  D:  Manageability:  Account 
ability;  key  action  audit  (e.g,  attribu¬ 
tion  of  who/ from  where  the  publish 
button  was  pressed  and  what  changes 
were  made);  auditing  capabilities. 

•  Group  E:  Usability:  Security  must  be 
manageable  and  not  hinder  business 
(where  possible);  must  be  available 
24/7  via  remote  authenticated  access; 
must  have  consistent  APIs;  must 
reduce  or  eliminate  risks  of  inadver¬ 
tent  behavior. 

•  Group  F:  Authentication:  Strong 
authentication. 

Details:  Benefits,  Proof,  Assumptions,  Iss¬ 
ues,  and  Action  Items.  In  Step  4,  the  par¬ 
ticipants  are  asked  to  evaluate  each  re¬ 
quirement  using  die  following  10  questions: 

1.  Is  the  candidate  requirement  a  frag¬ 
ment  or  duplicate  of  anything  that  has 
already  been  discussed? 

2.  According  to  the  contributor  and  the 
group,  is  the  candidate  requirement 
fragment  in  scope? 

3.  Would  you  like  to  change  the  title? 

4.  If  you  had  this  capability,  how  would  it 
help  the  business? 

5.  What  will  you  consider  acceptable  evi¬ 
dence  that  the  envisioned  capability 
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Figure  1 :  Ranked  Score  of  the  Requirements 


has  been  successfully  delivered  to  the  1. 
business? 

6.  Are  there  any  special  constraints  on  2. 
the  requirement? 


regarding  the  requirement? 


8.  What  are  the  remaining  issues  and 
actions  items  for  the  requirement? 

9.  Are  there  any  related  notes  or  com* 
ments? 

10.  Is  there  anything  that  needs  to  be 
clarified  by  the  supplier  of  the 
requirement? 

In  this  case,  the  security  requirements  were 
reviewed  collectively,  not  individually. 

Prioritization.  In  the  BON  step  of  ARM, 
the  participants  generate  the  candidate 
security  requirements  of  their  project, 
then  modify  and  refine  the  projected 
security  requirements  in  the  Details  step 
to  ensure  that  the  requirements  are 
unambiguous,  clear,  and  concise. 

The  Prioritization  phase  of  the  ARM 
method  begins  with  the  requirements 
engineering  team  providing  instructions 
to  guide  participants  to  label  each 
requirement  as  either  A,  B,  or  C,  where  A 
stands  for  most  important,  B  stands  for 
very  important,  and  C  stands  for  impor¬ 
tant.  The  rankings  are  to  be  assigned 
equally  across  the  security  requirements. 

After  the  session  concludes,  the  scores 
are  calculated.  First,  the  requirements 
engineering  team  substitutes  the  rankings 
A,  B,  and  C  with  numeric  values  9,  3,  and 
1,  respectively.  Then,  the  team  calculates 
the  average  score  of  each  requirement. 
The  results  are  shown  in  Figure  1. 

These  are  the  final  requirements  in 
priority  order: 


The  system  shall  utilize  cryptographi¬ 
cally  strong  authentication. 

The  information  in  die  system  must  be 
kept  private  from  unauthorized  users. 
The  system  shall  implement  selective¬ 
ly  secure  communication  with  outside 
entities. 

4.  The  system  shall  utilize  and  enforce 
an  access  control  system. 

5.  The  system  will  attempt  to  reduce  or 
eliminate  risks  of  inadvertent  behavior. 

6.  The  system  shall  provide  granular 
access  to  data  for  users  (operators) 
and  customers. 

7.  The  system  shall  provide  role-based, 
restricted  view,  edit,  and  action  access 
(e.g,  summary  report  information, 
public  for  particular  people). 

(tied  with) 

The  system  shall  represent  and  sup¬ 
port  segmented  disclosure. 

8.  The  system  shall  implement  auditing 
capabilities. 

9.  The  system  shall  provide  accountabil¬ 
ity  of  users’  actions. 

(tied  with) 

The  system  will  be  available  24/7  via 
remote  authenticated  access. 

10.  The  system  shall  maintain  a  parti¬ 
tioned  data  store  that  is  public  read 
only  and  private  read/write. 

(tied  with) 

The  system  shall  implement  a  key 
action  audit  (e.g,  attribution  of  who 
pressed  the  publish  button  and  from 
where,  and  what  changes  were  made). 

1 1.  The  system  shall  implement  indelibility. 
(tied  with) 

Where  possible,  the  system’s  security 
features  must  be  manageable  and  not 
hinder  business. 


12.  The  system  shall  expose  consistent 
APIs  to  developers. 

Based  on  the  result  of  the  prioritization, 
the  participants  can  then  develop  a  plan 
to  effectively  implement  their  security 
requirements. 

Stakeholders’  Feedback.  In  the  final 
portion  of  the  Session  phase,  the  team 
requested  that  the  participants  fill  out  a  feed¬ 
back  form  that  was  used  to  collect  informa¬ 
tion  to  improve  the  method.  Example  ques¬ 
tions  are  similar  to  the  following: 

•  What  did  you  like  or  not  like  about 
the  Session  phase? 

•  What  did  you  think  was  the  most 
important  part  of  the  Session  phase? 

•  What  would  you  change  about  the 
Session  phase? 

Deliverable  Closure 

In  this  study,  the  set  of  stakeholders  was 
relatively  small  and  Deliverable  closure 
took  place  informally  at  the  Session  phase. 

Results  Summary  for  ARM 

Overall,  ARM  is  an  effective  and  rapid 
method  of  collecting  requirements.  By 
simply  choosing  the  correct  focus  ques¬ 
tion,  the  process  is  easily  adapted  to  elic¬ 
it  security  requirements.  Due  to  the  large 
number  of  questions  that  must  be  asked 
for  each  requirement,  we  recommend 
enforcement  of  strict  time  management 
and  proactive  guidance  of  the  discus¬ 
sions  among  the  stakeholders. 

Depending  on  the  security  expertise 
of  the  participants,  the  requirements 
engineering  team  may  need  to  review 
some  security  concepts  with  the  partici¬ 
pants  before  the  session  begins. 

ARM  was  developed  for  use  in  a  com¬ 
mercial  environment,  and  thus,  may 
focus  excessively  on  features. 

Results  Summary  for  All 
Elicitation  Methods 

ARM  seemed  better  suited  to  elicitation 
of  security  requirements  than  either  IBIS 
or  JAD.  JAD  seemed  more  suited  to  end- 
user  functional  requirements  and  provid¬ 
ed  no  specific  way  to  discuss  quality 
requirements  such  as  security.  We  found 
that  IBIS  was  effective  for  documenting 
complex  decision-making  discussions  but 
did  not  provide  a  structured  way  of  gen¬ 
erating  security  requirements. 

We  later  experimented  with  other  pri¬ 
oritization  methods  [1],  notably  Analytic 
Hierarchy  Process  (AHP),  which  seemed 
to  provide  more  systematic  prioritization 
than  ARM. 

Future  Plans 

These  case  studies  are  part  of  the  securi- 
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ty  quality  requirements  engineering 
(SQUARE)  project  [13].  Current  plans 
call  for  a  comparison  of  SQUARE  with 
other  security  requirements  engineering 
methods,  experimental  combination  of 
elicitation  and  prioritization  methods  (for 
example,  combining  ARM  for  elicitation 
with  AHP  for  prioritization),  develop¬ 
ment  of  supporting  tools,  and  develop¬ 
ment  of  tutorial  materials. ♦ 
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